lock manager out of room
Otázka od: Lebeda David
8. 11. 2002 12:37
Ahoj,
co muzu pro to, aby me porad FB 1.0 neobtezoval nefunkcnosti z
duvodu %subj%?
Jediny navod, na ktery jsem narazil, je zvysit v souboru ibconfig
hodnotu parametru V4_LOCK_MEM_SIZE z implicitni hodnoty
98304 na 198304. To jsme udelali a hlaska se stale objevuje. Co to
vubec znamena a co ji hlavne zpusobuje? Je to kvuli spatne praci
se serverem nebo jde o externe neresitelnou chybu FB?
Uz opravdu zurim, protoze server FB se mi jevi jako dost nestabilni.
Pred 2 dny, po pouhem spusteni aplikace, na serveru vzniklo pres
150 procesu a neustale pribyvaly dalsi, az do totalniho zahlceni. Po
delsim patrani, co se deje, se ukazalo, ze za to muze z nejakeho
duvodu naboreny GDB soubor. OK, gfix opravil nejake chyby v
indexech stranek, udelala se zaloha a pri pokusu o obnovu to
vyhucelo s tim, ze "validation error on column B_RIZENY". Prislusny
sloupec je definovan jako NOT NULL, presto v nem byly 3 radky s
hodnotou NULL. Prusery to jsou 2:
1) To uz se opravdu nemohu spolehnout ani na bezchybnost v
techto zakladnich zalezitostech?
2) Ale hlavne - zakaznik si zalohuje, zalohuje, pak vyhori a co se
ukaze? Vsechny zalohy mu jsou na nic, protoze zaloha sla provest
bez problemu, zatimco obnova kvuli takoveto kravine neprojde.
Ale zpet k problemu viz %subj%. Vite nekdo neco?
Dik
David Lebeda
Odpovedá: Konference Delphi
8. 11. 2002 14:06
Ahoj,
jak to tak vidim, vychazim mi z toho jedine:
* je narusena databaze. Jedine vypustit a zase nafoukat.. 
k poruseni uplne staci, napriklad zipuje-li se primo GDB soubor. Pak po
obnove uz
je databaze casto narusena. Vzdy backupovat a pak zipovat.
* jake jsou hodnoty OIT OAT? Je-li mezi nimi velky rozdil tyto rozvirajici
se nuzky zpusobi ono zpomaleni serveru.
Rozdil mezi OIT a OAT muze byt zpusoben napr. neustale pripojenym
"hlidacem", ktery v jedne a te same transakci porad prochazi tabulku/y.
Pravidelny commit je zdravy.
Martin
----- Original Message -----
From: "Lebeda David" <david.lebeda@comarr.cz>
To: <delphi-l@clexpert.cz>
Sent: Friday, November 08, 2002 10:59 AM
Subject: lock manager out of room
> Ahoj,
>
> co muzu pro to, aby me porad FB 1.0 neobtezoval nefunkcnosti z
> duvodu %subj%?
>
> Jediny navod, na ktery jsem narazil, je zvysit v souboru ibconfig
> hodnotu parametru V4_LOCK_MEM_SIZE z implicitni hodnoty
> 98304 na 198304. To jsme udelali a hlaska se stale objevuje. Co to
> vubec znamena a co ji hlavne zpusobuje? Je to kvuli spatne praci
> se serverem nebo jde o externe neresitelnou chybu FB?
>
> Uz opravdu zurim, protoze server FB se mi jevi jako dost nestabilni.
> Pred 2 dny, po pouhem spusteni aplikace, na serveru vzniklo pres
> 150 procesu a neustale pribyvaly dalsi, az do totalniho zahlceni. Po
> delsim patrani, co se deje, se ukazalo, ze za to muze z nejakeho
> duvodu naboreny GDB soubor. OK, gfix opravil nejake chyby v
> indexech stranek, udelala se zaloha a pri pokusu o obnovu to
> vyhucelo s tim, ze "validation error on column B_RIZENY". Prislusny
> sloupec je definovan jako NOT NULL, presto v nem byly 3 radky s
> hodnotou NULL. Prusery to jsou 2:
>
> 1) To uz se opravdu nemohu spolehnout ani na bezchybnost v
> techto zakladnich zalezitostech?
>
> 2) Ale hlavne - zakaznik si zalohuje, zalohuje, pak vyhori a co se
> ukaze? Vsechny zalohy mu jsou na nic, protoze zaloha sla provest
> bez problemu, zatimco obnova kvuli takoveto kravine neprojde.
>
> Ale zpet k problemu viz %subj%. Vite nekdo neco?
>
> Dik
>
> David Lebeda
Odpovedá: Pavel Cisar
8. 11. 2002 17:48
Haj hou!
On 8 Nov 2002 at 10:59, Lebeda David wrote:
> Jediny navod, na ktery jsem narazil, je zvysit v souboru ibconfig
> hodnotu parametru V4_LOCK_MEM_SIZE z implicitni hodnoty
> 98304 na 198304. To jsme udelali a hlaska se stale objevuje.
A odstranili jste znak # (komentar) ze zacatku radku a restartovali
server ?
> Co to vubec znamena a co ji hlavne zpusobuje? Je to kvuli spatne praci
> se serverem nebo jde o externe neresitelnou chybu FB?
Externe je to resitelne zvysenim limitu v konfiguraci. Ne kazdy vyssi
limit potrebuje a IB pochazi z dob, kdy setrit pameti bylo treba, tolik k
duvodum proc je default tak maly. V ramci projektu Firebird se mluvilo o
zvyseni defaultni hodnoty nebo jeste lepe o dynamickem rozsirovani
tabulky. Dokud ovsem nebude nova varze, musite se smirit s konfiguracnim
souborem.
> Uz opravdu zurim, protoze server FB se mi jevi jako dost nestabilni.
Co to znamena nestabilni. Jake problemy mate. Mohu ze skusenosti rici, ze
vetsina uzivatelu si na zadnou nestabilitu nestezuje (i kdyz samozrejme
IB/FB neni bez chyb), takze i vase problemy by se zaiste daly odstranit
nebo alespon zmirnit.
> Pred 2 dny, po pouhem spusteni aplikace, na serveru vzniklo pres
> 150 procesu a neustale pribyvaly dalsi, az do totalniho zahlceni. Po
> delsim patrani, co se deje, se ukazalo, ze za to muze z nejakeho
> duvodu naboreny GDB soubor. OK, gfix opravil nejake chyby v
> indexech stranek, udelala se zaloha a pri pokusu o obnovu to
> vyhucelo s tim, ze "validation error on column B_RIZENY". Prislusny
> sloupec je definovan jako NOT NULL, presto v nem byly 3 radky s
> hodnotou NULL. Prusery to jsou 2:
>
> 1) To uz se opravdu nemohu spolehnout ani na bezchybnost v
> techto zakladnich zalezitostech?
Kdyby jste znal dokumentaci, tak by jste o tomto omezeni/problemu vedel.
Tento problem se nevyskytuje bezne, ale jsou presne zname a
zdokumentovane situace, kdy _muze_ vzniknout (a jak to resit).
> 2) Ale hlavne - zakaznik si zalohuje, zalohuje, pak vyhori a co se
> ukaze? Vsechny zalohy mu jsou na nic, protoze zaloha sla provest
> bez problemu, zatimco obnova kvuli takoveto kravine neprojde.
Z toho duvodu je nutne:
1) vedet kdy k tomuto muze dojit (v podstate jen pri zmene struktury jiz
naplnene databaze nebo poskozenim databaze).
2) Prijmout odpovidajici opatreni, tzn. obnovit cas od casu ze zalohy. To
je konec koncu doporuceny postup z mnoha duvodu. Pak se vam nestane, ze
vas tento problem zastihne v nepravy okamzik.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Lebeda David
11. 11. 2002 9:00
> > Jediny navod, na ktery jsem narazil, je zvysit v souboru ibconfig
> > hodnotu parametru V4_LOCK_MEM_SIZE z implicitni hodnoty 98304 na
> > 198304. To jsme udelali a hlaska se stale objevuje.
>
> A odstranili jste znak # (komentar) ze zacatku radku a restartovali
> server ?
Jiste, uz jednou jsem se takhle spalil, takze uz to vim.
>
> > Co to vubec znamena a co ji hlavne zpusobuje? Je to kvuli spatne
> > praci se serverem nebo jde o externe neresitelnou chybu FB?
>
> Externe je to resitelne zvysenim limitu v konfiguraci.
Dokud ovsem nebude nova varze, musite se smirit s
> konfiguracnim souborem.
Mne konfiguracni soubor nevadi. Prosim vsak i info:
1) Hodnota 198 304 je maximalni, nebo mohu jeste pridat? Pokud neni maximalni,
kam az muzu zvysovat?
2) Da se nejak strucne a velmi principialne vysvetlit, o co jde? Pod pojmem
lock
manager bych ocekaval spravce uzamceni zaznamu, a v takovem pripade by k
uvolneni treba mohlo stacit to, ze se vsichni od serveru odhlasi. Na druhou
stanu -
pocet uzivatelu je jednociferny, nevim, proc by meli lock manager zahltit, ale
budiz.
Chtel bych se aspon castecne dostat do obrazu, ceho se vlastne ten problem
tyka.
>
> Co to znamena nestabilni. Jake problemy mate.
Prave ze to se tezko popisuje. Je nas tady v tymu 6 a ladime aplikace nad vetsi
databazi (nekolik set tabulek, pres 1000 triggeru). Na jednom FB serveru jsou
tri
databaze (stejna struktura, ruzna data).
1) Stava se casteji nez vyjimecne, ze pri pokusu o prihlaseni k jedne databazi
vyskoci lock manager out of room, zatimco s jinou se da pracovat v pohode.
Pritom
s databazi, na ktere hlaska vyskakuje, v dane chvili nikdo nepracuje, nebo max.
5
lidi.
2) Hodne casto musim pozadat spravce serveru, aby FB utal a restartoval, nekdy
je
treba restart celeho stroje. Bud na serveru vyskoci pres 100 procesu IBSERVER a
tim ho zahlti, nebo tech vlaken je par, ale jedno jede ne 98% a cele je to tim
vytuhle.
Vlakno pritom nezmizi ani pote, co se vsichni odhlasi. K tomu nekdy staci treba
z
IBConsole zadat nejaky select (to jiste neni spousteci mechanismus, ale jen
nejaka
zaminka).
Nad databazi se pritom nedelaji zadne nezvyklosti, proste bezny provoz pomoci
SQL
jazyka.
3) Cas od casu se ukaze, ze je naboreny gdb soubor. Pritom vsude zastanci SQL
serveru tvrdi, ze "se to (skoro) nemuze stat". Kdyby to bylo vyjimecne,
nevadilo by
to. Ale tady se to stava sice ne zcela bezne, ale pritom dostatecne casto na
to,
abychom si toho vsimli. Pokud by se to takhle melo chovat u zakaznika, tak nas
vypiska.
Nevim, kde je problem, ale nezpusobuji ho vypadky proudu. Proste jen bezny
provoz. Je pravda, ze se prubezne doplnuje struktura databaze (SQL skriptem).
To
by snad nemelo gdb soubor rozhodit.
> Kdyby jste znal dokumentaci
Mam k dispozici pouze dokumentaci k IB6. Samozrejme ji neumim zpameti, takze je
mozne, ze se tam o resenem problemu neco pise, ale uznavam, ze bych mel o
dokumentaci mit lepsi prehled, nez mam nyni. Existuje uz dokumentace primo k FB
nebo treba nejaky plan, kdy bude?
Jinak diky za reakci, jsem rad, ze ten dotaz nezmizel do ztracena, a kdyz se
ukaze,
ze chyba je na me strane a ze ji tudiz muzu odstranit, bude to jen dobre. Ale
zatim o
takove chybe nevim.
V tuto chvili ale prosim neresme ten pomerne vagne popsany a zmapovany problem,
ktery jsem oznacil jako nestabilita. To by asi chtelo hlubsi pozorovani a
rozbor.
Ale jestli muzu poprosit o povidani k lock manager out of room, jak pisu vyse,
to
bych opravdu rad. Diky.
David Lebeda
Odpovedá: Karel Rys
11. 11. 2002 9:22
Lebeda David dne 11 Nov 2002 v 7:56:
> 3) Cas od casu se ukaze, ze je naboreny gdb soubor. Pritom vsude
> zastanci SQL serveru tvrdi, ze "se to (skoro) nemuze stat". Kdyby to
> bylo vyjimecne, nevadilo by to. Ale tady se to stava sice ne zcela
> bezne, ale pritom dostatecne casto na to, abychom si toho vsimli.
> Pokud by se to takhle melo chovat u zakaznika, tak nas vypiska.
>
> Nevim, kde je problem, ale nezpusobuji ho vypadky proudu. Proste jen
> bezny provoz. Je pravda, ze se prubezne doplnuje struktura databaze
> (SQL skriptem). To by snad nemelo gdb soubor rozhodit.
Ahoj,
u IB serveru se mi tohle taky zpocatku stavalo (server byl na UPS, Win 2000).
Zda se, ze to bylo
bud proto, ze jsem (hloupe) nastavil v konfiguracnim souboru
DATABASE_CACHE_PAGES na cislo vetsi
nez 10000 (coz se, jak jsem se pak nekde docetl, nema - pry kvuli vykonu, ale
kdo vi...), nebo
proto, ze jsem u databaze nemel nastaveno Forced Writes na true. Kdyz jsem
tohle (oboje najednou)
zmenil, problemy naruseneho .gdb souboru prestaly.
Karel Rys
Odpovedá: Pavel Cisar
11. 11. 2002 12:45
Haj hou!
On 11 Nov 2002 at 7:56, Lebeda David wrote:
> 1) Hodnota 198 304 je maximalni, nebo mohu jeste pridat? Pokud neni
maximalni,
> kam az muzu zvysovat?
Muzete pridat. Maximalni hodnota je dana jadrem operacniho systememu (na
Linux/UNIX se muze lisit dle verze a buildu jadra). Pokud narazite na
problemy, podivejte se na
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_sem_sm
> 2) Da se nejak strucne a velmi principialne vysvetlit, o co jde? Pod pojmem
lock
> manager bych ocekaval spravce uzamceni zaznamu, a v takovem pripade by k
> uvolneni treba mohlo stacit to, ze se vsichni od serveru odhlasi. Na druhou
stanu -
> pocet uzivatelu je jednociferny, nevim, proc by meli lock manager zahltit,
ale budiz.
> Chtel bych se aspon castecne dostat do obrazu, ceho se vlastne ten problem
tyka.
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_config
> Prave ze to se tezko popisuje. Je nas tady v tymu 6 a ladime aplikace nad
vetsi
> databazi (nekolik set tabulek, pres 1000 triggeru). Na jednom FB serveru jsou
tri
> databaze (stejna struktura, ruzna data).
>
> 1) Stava se casteji nez vyjimecne, ze pri pokusu o prihlaseni k jedne
databazi
> vyskoci lock manager out of room, zatimco s jinou se da pracovat v pohode.
Pritom
> s databazi, na ktere hlaska vyskakuje, v dane chvili nikdo nepracuje, nebo
max. 5
> lidi.
Kazda databaze si sice alokuje vlastni page cache, ale pokud si dobre
pamatuji, tak lock manager je jen jeden pro vsechny. Podivejte se na
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_config
a problem vam bude mnohem jasnejsi.
> 2) Hodne casto musim pozadat spravce serveru, aby FB utal a restartoval,
nekdy je
> treba restart celeho stroje. Bud na serveru vyskoci pres 100 procesu IBSERVER
a
> tim ho zahlti, nebo tech vlaken je par, ale jedno jede ne 98% a cele je to
tim vytuhle.
> Vlakno pritom nezmizi ani pote, co se vsichni odhlasi. K tomu nekdy staci
treba z
> IBConsole zadat nejaky select (to jiste neni spousteci mechanismus, ale jen
nejaka
> zaminka).
>
> 3) Cas od casu se ukaze, ze je naboreny gdb soubor. Pritom vsude zastanci SQL
> serveru tvrdi, ze "se to (skoro) nemuze stat". Kdyby to bylo vyjimecne,
nevadilo by
> to. Ale tady se to stava sice ne zcela bezne, ale pritom dostatecne casto na
to,
> abychom si toho vsimli. Pokud by se to takhle melo chovat u zakaznika, tak
nas
> vypiska.
Mno, pokud mate forced writes vypnuto a sem tam pozadata administratora
aby server natvrdo sestrelil, tak se nedivte ze mate cas od casu
naborenou databazi. Sestreleni serveru vzdy zanese do databze nejake
seno, ktere pripadne gfix nahlasi a gbak backup/restore odstrani. Tohle
seno je ovsem pri FW ON benigni, kdezto jinak je to vetsinou pruser.
> Mam k dispozici pouze dokumentaci k IB6. Samozrejme ji neumim zpameti, takze
je
> mozne, ze se tam o resenem problemu neco pise, ale uznavam, ze bych mel o
> dokumentaci mit lepsi prehled, nez mam nyni. Existuje uz dokumentace primo k
FB
> nebo treba nejaky plan, kdy bude?
Mno, dokumentace k IB6 by mohla stacit, jinak pro FB je anglicka
dokumentace k dispozici od IBPhoenixu na poslednim distribucnim CD. A
pristi rok by u nas mela vyjit knizka.
S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Vladimir Michl
13. 11. 2002 16:41
On Mon, 11 Nov 2002, Pavel Cisar wrote:
> Mno, pokud mate forced writes vypnuto a sem tam pozadata administratora
> aby server natvrdo sestrelil, tak se nedivte ze mate cas od casu
> naborenou databazi. Sestreleni serveru vzdy zanese do databze nejake
> seno, ktere pripadne gfix nahlasi a gbak backup/restore odstrani. Tohle
> seno je ovsem pri FW ON benigni, kdezto jinak je to vetsinou pruser.
Jen se ujistim. Pokud ukoncim FB server pomoci ibmgr na UNIXu ci v
ovladacich panelech pres Interbase manager a neni zapnuto forced writes,
tak k ulozeni sena do DB, tedy k moznemu poskozeni .gdb, nedojde?
Nebo i pri tomto muze dojit k poskozeni .gdb (pokud jsou prihlaseni
nekteri uzivatele).
---------------------------------------------------------------------------
Vladimír Michl <Vladimir.Michl@hlubocky.del.cz>
Del a.s., Strojírenská 38, ďár nad Sázavou
pobočka Olomoucká 355, Hlubočky-Mariánské Údolí
tel: +420 585 353 548, fax: +420 585 352 364
http://hlubocky.del.cz
Odpovedá: Skopalik Slavomir
13. 11. 2002 16:23
Tohle NENI tvrde sestreleni. Tvrde sestreleni ve windows lze napriklad v
aplikacnim rezimu
pres spravce uloh (na sluzbu nema uzivatel opravneni), nebo pres handleex.
Slavek
> Jen se ujistim. Pokud ukoncim FB server pomoci ibmgr na UNIXu ci v
> ovladacich panelech pres Interbase manager a neni zapnuto forced writes,
> tak k ulozeni sena do DB, tedy k moznemu poskozeni .gdb, nedojde?
>
> Nebo i pri tomto muze dojit k poskozeni .gdb (pokud jsou prihlaseni
> nekteri uzivatele).